home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ien / ien-131 < prev    next >
Encoding:
Text File  |  1988-12-01  |  18.3 KB  |  574 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.                        Gateway Monitoring Protocol
  9.  
  10.  
  11.                                  IEN 131
  12.  
  13.  
  14.                              1 February 1980
  15.  
  16.  
  17.  
  18.  
  19.  
  20.  
  21.  
  22.  
  23.  
  24.  
  25.                              David Flood Page
  26.  
  27.  
  28.  
  29.  
  30.  
  31.  
  32.  
  33.  
  34.  
  35.  
  36.                       Bolt, Beranek and Newman Inc.
  37.                             50 Moulton Street
  38.                       Cambridge, Massachusetts 02238
  39.  
  40.  
  41.                               (617) 491-1850
  42.  
  43.  
  44.  
  45.  
  46.                         GATEWAY MONITORING PROTOCOL
  47.  
  48.  
  49.  
  50.  
  51.     1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
  52.  
  53.  
  54.     2.  Communication Mechanism  . . . . . . . . . . . . . . . . . . 2
  55.  
  56.       2.1  Negotiation . . . . . . . . . . . . . . . . . . . . . . . 2
  57.  
  58.       2.2  Requesting Reports  . . . . . . . . . . . . . . . . . . . 3
  59.  
  60.       2.3  Requesting Traps  . . . . . . . . . . . . . . . . . . . . 4
  61.  
  62.  
  63.     3.  Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 4
  64.  
  65.       3.1  Report Formats  . . . . . . . . . . . . . . . . . . . . . 7
  66.  
  67.         3.1.1  Gateway description - type 0  . . . . . . . . . . . . 7
  68.  
  69.         3.1.2  Echo - type 1 . . . . . . . . . . . . . . . . . . . . 7
  70.  
  71.         3.1.3  Throughput matrix - type 2  . . . . . . . . . . . . . 7
  72.  
  73.         3.1.4  Status of all interfaces - type 3 . . . . . . . . . . 7
  74.  
  75.         3.1.5  Queue activity - type 4 . . . . . . . . . . . . . . . 8
  76.  
  77.         3.1.6  End to end statistics - type 5  . . . . . . . . . . . 8
  78.  
  79.         3.1.7  Individual interface status - type 6  . . . . . . . . 8
  80.  
  81.         3.1.8  Routing tables - type 7 . . . . . . . . . . . . . . . 9
  82.  
  83.       3.2  Trap Formats  . . . . . . . . . . . . . . . . . . . . . . 9
  84.  
  85.         3.2.1  Interface up/down - type 1  . . . . . . . . . . . . . 9
  86.  
  87.         3.2.2  Neighbor gateway up/down - type 2 . . . . . . . . . . 9
  88.  
  89.         3.2.3  Queue full - type 3 . . . . . . . . . . . . . . . . . 9
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.                                   - 1 -
  101.  
  102.     IEN 131            Gateway Monitoring Protocol
  103.  
  104.  
  105.     1.  Introduction
  106.  
  107.          This document details the protocol for the gateway monitoring
  108.     functions described in  IEN  105,  'ARPA  Catenet  Monitoring  and
  109.     Control'.   It  does  not deal with the control functions or fault
  110.     isolation;  these will be covered in a separate document.
  111.  
  112.          The protocol described  here  contains  a  number  of  report
  113.     types.   We  realize  that  to  implement  them  all may impose an
  114.     unacceptable load on a gateway;  therefore the system is  designed
  115.     to cater to gateways not implementing the complete protocol.
  116.  
  117.  
  118.          The protocol is described in two parts:
  119.  
  120.               - Communication mechanism
  121.               - Data formats
  122.  
  123.  
  124.     2.  Communication Mechanism
  125.  
  126.     2.1  Negotiation
  127.  
  128.          Because  a  gateway  may not implement the complete protocol,
  129.     the Catenet Monitoring  and  Control  Center  (CMCC)  is  able  to
  130.     discover,  each  time it makes a request of a gateway, whether the
  131.     gateway can satisfy that request.  The method used is  similar  to
  132.     the  DO  -  DONT  -  WILL - WONT mechanism in the Telnet protocol.
  133.     Briefly, this works as follows:
  134.  
  135.          When the CMCC wants to obtain information from a gateway,  it
  136.     sends a DO message to the gateway.  If the gateway is able to make
  137.     the  required  response,  it returns a WILL message accompanied by
  138.     the data requested.  If it cannot do this, it sends  back  a  WONT
  139.     message  detailing  why  it could not satisfy the request.  If the
  140.     gateway does not even implement this negotiation mechanism, or  if
  141.     the  message  is  lost  in  transit, then the CMCC will receive no
  142.     reply.  In this case it will try up to two more times at 30 second
  143.     intervals.  If it still gets no reply, then it acts as if  a  WONT
  144.     message had been received.
  145.  
  146.          If   the   CMCC  wants  to  stop  the  gateway  from  sending
  147.     information, then it sends  a  DONT  message.   The  gateway  then
  148.     responds  with a WONT reply.  The CMCC will try up to three times,
  149.     at 30 second intervals, to get this acknowledgement.
  150.  
  151.          A gateway will need to implement this  negotiation  mechanism
  152.     in  order  to  participate  in  the Monitoring and control system.
  153.     This is true regardless of  how  many  of  the  report  types  are
  154.     implemented in the gateway.
  155.  
  156.  
  157.  
  158.  
  159.                                   - 2 -
  160.  
  161.     IEN 131            Gateway Monitoring Protocol
  162.  
  163.  
  164.     2.2  Requesting Reports
  165.  
  166.          Gateways  may be requested to send out a series of reports at
  167.     regular intervals, as well as just sending back a single response.
  168.     So a DO REPORT request contains, in addition to the  report  type,
  169.     the  number  of reports required and the interval between reports.
  170.     The number of reports may  be  a  special  value  (65535)  meaning
  171.     'until further notice'.  When the CMCC wants to turn off this kind
  172.     of  report  then  it  sends  a  DONT  message to the gateway.  The
  173.     gateway will then cease reporting and send back  a  WONT  message.
  174.     The  CMCC  will  send up to 3 DONT messages until it gets the WONT
  175.     response.  If it still receives no answer then it gives up.
  176.  
  177.          If a gateway is sending out regular reports, and it  receives
  178.     a new request from the same source as the original request to send
  179.     the  same  report, then the new request is considered to supercede
  180.     the old one unless the new request is for  a  single  report.   In
  181.     this  case  the  gateway  should  make  the  single  response, but
  182.     continue sending the regular reports.  If the new request  is  for
  183.     more  than  one report, then the gateway should reset the sequence
  184.     number (see below) and forget about  the  original  request.   The
  185.     question  of  dealing  with  requests from different sources is in
  186.     part an authorization question, and is  not  dealt  with  in  this
  187.     document;  however,  gateways  should  in  general  be prepared to
  188.     satisfy requests for single reports from any source at  any  time.
  189.  
  190.          A  gateway  may be unable to send out more than one report in
  191.     response to a single enquiry;  i.e. it may insist on being polled.
  192.     If such a gateway receives a  request  for  multiple  reports,  it
  193.     sends  back  a  WONT  REPORT  reply, indicating that the number of
  194.     reports in the request was unacceptable.  The CMCC will then  send
  195.     a  single report request, and will continue sending these requests
  196.     at appropriate intervals.
  197.  
  198.          Each request  sent  out  from  the  CMCC  contains  a  report
  199.     identification  number.  This number is returned by the gateway in
  200.     the WILL REPORT or WONT REPORT message.  When a request results in
  201.     more than one  report  message,  those  after  the  first  have  a
  202.     sequence number instead of the report id.  Gateways will reset the
  203.     sequence  number when they receive a DO REPORT, except in the case
  204.     of a single report request as described  above.   When  a  regular
  205.     report  is requested, the WILL REPORT reply may or may not contain
  206.     the first report message.  If it does not, then it should  consist
  207.     only of the WILL REPORT header, with no extra data.
  208.  
  209.  
  210.          The following is a list of the report types.
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.                                   - 3 -
  219.  
  220.     IEN 131            Gateway Monitoring Protocol
  221.  
  222.  
  223.      Type
  224.  
  225.       0 - Gateway description.
  226.       1 - Echo.
  227.       2 - Throughput transit matrix.
  228.       3 - Interface up/down status for all interfaces.
  229.       4 - Queue activity.
  230.       5 - End to end traffic statistics.
  231.       6 - Individual interface status.
  232.       7 - Routing table.
  233.  
  234.  
  235.     2.3  Requesting Traps
  236.  
  237.          Besides  the  reports,  a  gateway may issue traps, which are
  238.     messages announcing some event in the gateway.  A gateway  may  be
  239.     directed  to  start  or  stop  sending the various kinds of traps,
  240.     using DO - DONT - WILL - WONT TRAP messages in  the  same  way  as
  241.     REPORT  messages  are  used,  except  that  normally the WILL TRAP
  242.     message will not be accompanied by data.
  243.  
  244.          The following is a list of the trap types:
  245.  
  246.      Type
  247.  
  248.       1 - Interface up/down.
  249.       2 - Neighbor gateway up/down.
  250.       3 - Queue full.
  251.  
  252.          Here, up/down on an interface refers to the ready line.   For
  253.     a   neighbor   gateway   it   is   determined   according  to  the
  254.     gateway-gateway protocol in force.
  255.  
  256.     3.  Data Formats
  257.  
  258.          Bits within a field are numbered starting at  0  and  ordered
  259.     left  to right, so that an octet with bit 0 set on has the numeric
  260.     value 128.  Octets within numeric fields of more than 8  bits  are
  261.     ordered  so  that  the  most  significant  octet comes first.  For
  262.     example, a 32 bit numeric field with a value  of  65536  would  be
  263.     expressed  as  0,1,0,0 in octets.  For other fields of more than 8
  264.     bits, the first octet contains bits 0-7, the second 8-15,  and  so
  265.     on.
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.                                   - 4 -
  278.  
  279.     IEN 131            Gateway Monitoring Protocol
  280.  
  281.  
  282.          Monitoring Packets have the following format:
  283.  
  284.                           +--------------------+
  285.                           !   Local Header     !
  286.                           +--------------------+
  287.                           ! Internet  Header   !
  288.                           +--------------------+
  289.                           ! Monitoring Header  !
  290.                           +--------------------+
  291.                           !        Data        !
  292.                           +--------------------+
  293.  
  294.     The data may be absent.
  295.  
  296.          The monitoring header has the following format:
  297.  
  298.      Bits          Contents
  299.  
  300.        0           0 - Report or trap
  301.                    1 - Negotiation message.
  302.  
  303.        1           0 - Report
  304.                    1 - Trap
  305.  
  306.      2-3           For a negotiation message:
  307.                    0 - DO
  308.                    1 - DONT
  309.                    2 - WILL
  310.                    3 - WONT
  311.                    For a report or trap: zero.
  312.  
  313.      4-7           Reserved for future use.
  314.  
  315.      8-15          Report or trap type.
  316.  
  317.     16-31          For a negotiation message: Report Id.
  318.                    For a report: Sequence number.
  319.                    For a trap: data depending on trap type.
  320.  
  321.     A DO REPORT message has the header:
  322.  
  323.        0   1   2   3   4   5   6   7  8            15 16         31
  324.      +-------------------------------------------------------------+
  325.      ! 1 ! 0 ! 0   0 ! 0   0   0   0 !  report type  !  report id  !
  326.      +-------------------------------------------------------------+
  327.  
  328.  
  329.     and the corresponding WILL REPORT message has:
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.                                   - 5 -
  337.  
  338.     IEN 131            Gateway Monitoring Protocol
  339.  
  340.  
  341.        0   1   2   3   4   5   6   7  8            15 16         31
  342.      +-------------------------------------------------------------+
  343.      ! 1 ! 0 ! 1   0 ! 0   0   0   0 !  report type  !  report id  !
  344.      +-------------------------------------------------------------+
  345.  
  346.     where  the  report  id  is  the  same as in the DO REPORT.  A DONT
  347.     REPORT will begin with:
  348.  
  349.        0   1   2   3   4   5   6   7  8            15 16         31
  350.      +-------------------------------------------------------------+
  351.      ! 1 ! 0 ! 0   1 ! 0   0   0   0 !  report type  !  report id  !
  352.      +-------------------------------------------------------------+
  353.  
  354.     and a WONT REPORT begins with:
  355.  
  356.        0   1   2   3   4   5   6   7  8            15 16         31
  357.      +-------------------------------------------------------------+
  358.      ! 1 ! 0 ! 1   1 ! 0   0   0   0 !  report type  !  report id  !
  359.      +-------------------------------------------------------------+
  360.  
  361.          Headers for trap negotiation messages are similar except that
  362.     bit 1 is 1 instead of 0.
  363.  
  364.          Trap messages have a header of only 2 octets:
  365.  
  366.               0   1   2   3   4   5   6   7  8            15
  367.             +-----------------------------------------------+
  368.             ! 0 ! 1 ! 0   0 ! 0   0   0   0 !   trap type   !
  369.             +-----------------------------------------------+
  370.  
  371.          DONT messages have no data.  The WONT header is followed by a
  372.     single octet which indicates which field(s)  in  the  request  the
  373.     gateway  objected  to.  Bits are set on according to the offending
  374.     field, as follows:
  375.  
  376.          Bit    Field
  377.           0     report or trap  (i.e the gateway has not implemented
  378.                                   any reports, or traps)
  379.           1     report/trap type
  380.           2     number of reports  (i.e. a gateway insists on being
  381.                                         polled)
  382.           3     reporting interval
  383.  
  384.          DO REPORT messages have two  16-bit  numbers  which  are  the
  385.     number  of reports required and the reporting interval in seconds,
  386.     in that order.  A request for 65535 reports means  'until  further
  387.     notice'.  In addition, a type 6 report request has one extra octet
  388.     at the end containing the interface number.
  389.  
  390.          The first response in any set of reports may also be the WILL
  391.     REPORT  negotiation  message  and  if  so, the first 4 bits of the
  392.     monitoring header will have the value 1010  (negotiation,  report,
  393.  
  394.  
  395.                                   - 6 -
  396.  
  397.     IEN 131            Gateway Monitoring Protocol
  398.  
  399.  
  400.     WILL).   Subsequent  reports  arising from the same request have a
  401.     header beginning with 0000 (report/trap, report,  zero).   If  the
  402.     first  response  is  the  WILL  REPORT  without any data, then its
  403.     length must be 4 bytes, i.e. it consists only  of  the  monitoring
  404.     header.
  405.  
  406.          Trap  messages may or may not have any data, depending on the
  407.     trap type.
  408.  
  409.     3.1  Report Formats
  410.  
  411.     3.1.1  Gateway description - type 0
  412.  
  413.          The first item is  the  gateway  name  as  four  8-bit  ASCII
  414.     characters.   The  next item consists of two octets containing the
  415.     number of interfaces in the gateway, and the number  of  neighbors
  416.     the gateway has, in that order.  This is then followed by two sets
  417.     of  32  bit numbers, whose size is given by the above octets.  The
  418.     first set lists the addresses of each interface  in  the  gateway,
  419.     and the second set lists the addresses of the gateway's neighbors.
  420.  
  421.     3.1.2  Echo - type 1
  422.  
  423.          There  is  no  data in this message type.  The gateway simply
  424.     returns the message to the place that sent it.
  425.  
  426.     3.1.3  Throughput matrix - type 2
  427.  
  428.          The report is a conceptual matrix with rows corresponding  to
  429.     output interfaces and columns to input interfaces.  The interfaces
  430.     are  numbered  from  0  to  N-1  and  there is an extra column for
  431.     packets dropped at the interface.
  432.  
  433.          The matrix is expressed as N * (N+1) 32-bit counts,  where  N
  434.     is the number of interfaces.  Each packet entering the gateway via
  435.     interface  IN  and  leaving  via interface OUT causes the count at
  436.     position (OUT * N) + IN to be incremented.
  437.  
  438.     3.1.4  Status of all interfaces - type 3
  439.  
  440.          The header is followed by a bit array in  which  the  bit  in
  441.     position i is 1 if interface i is up, 0 if it is down.  Interfaces
  442.     are  numbered  starting at zero, as in the throughput matrix.  The
  443.     ordering of the interfaces is defined in the  Gateway  Description
  444.     message, 3.1.1.
  445.  
  446.  
  447.  
  448.  
  449.  
  450.  
  451.  
  452.  
  453.  
  454.                                   - 7 -
  455.  
  456.     IEN 131            Gateway Monitoring Protocol
  457.  
  458.  
  459.     3.1.5  Queue activity - type 4
  460.  
  461.          The  header  is  followed  by  a set of reports, one for each
  462.     interface number.  Each report in the set is 16 bits long and  has
  463.     the following format:
  464.  
  465.      Bits     Contents
  466.  
  467.      0-7      Length of input queue for this interface.
  468.      8-15     Length of output queue.
  469.  
  470.          Interface numbering is as in the interface status message.
  471.  
  472.     3.1.6  End to end statistics - type 5
  473.  
  474.          The   report   has   a   set   of   counts,   one   for  each
  475.     source/destination combination.  The format of each entry is:
  476.  
  477.      Bits      Contents
  478.  
  479.      0-7       Source network number.
  480.      8-15      Destination network number.
  481.      16-47     Count of packets source-destination.
  482.  
  483.          The  counts  are  cumulative  and   so   is   the   list   of
  484.     source/destination  combinations,  i.e.  the  report  will contain
  485.     counts for every source/destination pair that  has  been  recorded
  486.     since the gateway started up.
  487.  
  488.     3.1.7  Individual interface status - type 6
  489.  
  490.          A  distinction  here  is  made  between  error free and error
  491.     handling interfaces.  The first four octets are the same  in  each
  492.     case,  except  for  a  code indicating the interface type.  For an
  493.     error free interface, these four octets are the whole report.  For
  494.     a VDH error handling interface  there  are  another  three  32-bit
  495.     counts of :
  496.  
  497.      packet framing errors
  498.      packets received with bad checksum
  499.      packets retransmitted
  500.  
  501.          The format of the first four octets is:
  502.  
  503.      Bits        Contents
  504.  
  505.      0-7         Interface number
  506.      8-11        Status: 0 (down), 1 (up)
  507.      12-15       Interface type: 0 - error free, 1 - VDH.
  508.      16-31       Number of times this interface has gone down.
  509.  
  510.  
  511.  
  512.  
  513.                                   - 8 -
  514.  
  515.     IEN 131            Gateway Monitoring Protocol
  516.  
  517.  
  518.          The down count is only reset at gateway startup time.
  519.  
  520.     3.1.8  Routing tables - type 7
  521.  
  522.          This  is a table of variable length entries each containing a
  523.     network number, the minimum distance  to  that  network  from  the
  524.     gateway,  and  the  addresses  of  each  neighbor  on  the minimum
  525.     distance path.  The format of each entry is as follows:
  526.  
  527.       8 bits number of neighbors
  528.       8 bits network number
  529.       8 bits distance to network
  530.       8 bits unused (allows 32-bit alignment of addresses)
  531.       32 bits first neighbor address
  532.       32 bits second neighbor address
  533.       (as many more neighbor addresses as necessary).
  534.  
  535.     3.2  Trap Formats
  536.  
  537.          Traps  all  have  a  16-bit   header   starting   with   0100
  538.     (report/trap, trap, zero).  Data for the traps is as follows.
  539.  
  540.     3.2.1  Interface up/down - type 1
  541.  
  542.        Bits    Contents
  543.  
  544.        0-7     up (1) or down (0).
  545.        8-15    interface number.
  546.  
  547.     3.2.2  Neighbor gateway up/down - type 2
  548.  
  549.        Bits    Contents
  550.  
  551.        0-3     up (1) or down (0).
  552.        4-7     old gateway (zero) or new gateway (1).
  553.        8-15    unused (for 32-bit alignment of next field)
  554.        16-47   Neighbor gateway internet address.
  555.  
  556.          A  new  gateway  is one not previously heard from, which will
  557.     therefore cause an addition to the gateway's routing tables.
  558.  
  559.     3.2.3  Queue full - type 3
  560.  
  561.        Bits    Contents
  562.  
  563.        0-7     Interface number for queue.
  564.        8-15    Input (zero) or output (1) queue.
  565.  
  566.  
  567.  
  568.  
  569.  
  570.  
  571.  
  572.                                   - 9 -
  573.  
  574.